Why I Like Modeling IoT Devices with Azure Service Fabric Actors

Service Fabric Actors offer a simple, reliable programming model to efficiently act as an IoT Device Shadow.  Device Shadow is the concept used when a software entity (a class, a service, etc.) is used to contain the recent state of an individual remote IoT device.  By “state” I mean the current data that an IoT device is designed to furnish to an IoT system.  For example, the state of a remote oil temperature sensor device would be the current temperature of the oil it is monitoring.   Device Shadows are often implemented with a JSON document, but here I use Service Fabric Actors.

Essentially, a Device Shadow is a virtual representation of a remote IoT device.  It contains the persistent recent state of the device.  A Device Shadow is used by the rest of the software system in an IoT solution to access a device’s state to avoid a time consuming and resource expensive process of gathering the state information from various places in an IoT system, perhaps including a trip all the way out to the remote IoT device to get it’s state.  Continuing the previous example, with a Device Shadow for an oil temperature sensor device the software does not need to ask the sensor device directly for its current measurement.  Nor does the software have to do a series of database queries to get the current state of a device saved in disk storage. Rather, the software can simply query the associated Device Shadow instead, since it contains all of a device’s recent state in one place.  This assumes the rest of the system is designed to have the IoT devices periodically report their state to their Device Shadow — A standard practice.   There may be dozens to 100s of thousands or more of remote devices and their Device Shadows in an IoT System!  The ability to deal with such massive scale is extremely important here.

Service Fabric is Microsoft’s next-generation middleware platform that has strong support for high scale microservices.  And it is aimed at providing very high reliability achieved by having multiple replicas of each service it hosts running on multiple virtual machines that make up a Service Fabric cluster.   Only the “primary replica” is used, but the “secondary replicas” in standby on other virtual machines in the cluster have their state always kept up to date with that of the primary replica.  This allows for very quick and precisely accurate automatic recovery from a crashed virtual machine in the cluster.  No operator involvement is required for this recovery.

A Service Fabric Actor is a highly reliable, single threaded, persistently stateful microservice that runs in a Service Fabric cluster.  Actors support high scale and high reliability since each one is a special Service Fabric Reliable Stateful Service that runs under control of the Service Fabric Actor Service which provides them with the unique characteristics of Actors.  Thus, SF Stateful Actors are very well suited to act as a Device Shadow.  And, since they are individual microservices, they can scale out without a negative impact on the code, operations, or performance of the overall software system.

Here is a conceptual data flow diagram showing how Service Fabric Actors can implement the Device Shadow role in an Azure IoT solution.

I have omitted detail in Figure 1 so as to focus only on the Actors and the flow of commands, command responses, and telemetry in the solution.  Please see “Microsoft IoT Reference Architecture” for definitions of terms used above.

The Business Backend System (Backend for short) is responsible for the UI display of alerts, dashboards, visualizations, and reports, plus some analysis of data, provisioning the system’s resources, and monitoring the health of the system as it runs.  The Backend also is responsible for issuing commands to remote IoT devices through Device Shadows as directed by user interaction with the UI or a via a programmatic workflow. The Device Shadow Actors are intermediaries, standing between Backend System and the Cloud IoT System (with its IoT Gateway data ingestion buffer to which the IoT devices connect).

During December 2016 and January 2017 I implemented an exploratory proof of concept (POC) system that used SF Stateful Actors as Device Shadows.  A challenging feature of my POC is that it had a requirement to implement significant commanding from the Backend System to the IoT devices.  Specifically, I had to make the IoT devices start, stop, and when running put them online and take them off line.  Commanding devices entails a lot more than just passively collecting telemetry from sensors, as is common in many IoT solutions.

Commanding involves the Device Shadows maintaining the command state of a remote device, in addition to its telemetry state.  It also requires a Device Shadow to implement behavior to support commanding.  Specifically, the Device Shadow must receive a command from the Backend System and then send the command to the correct remote device, allowing time for the device to execute the command, and then receive a command response from the IoT device when the device has completed command execution.  In addition, the Device Shadow needs the ability to time-out when no command response is received within a specified time.  And, the Device Shadows must know when a command is in the process of being executed by a device so as to prevent attempts to have the device execute multiple commands concurrently.  Finally, in all of the above scenarios a Device Shadow Actor must notify the Backend System of the command state at critical junctures in the commanding process, e. g. normal command completion, command time out, device error, etc.  These command response notifications allow the Backend to push them to UI client’s for alerts and dashboard updates.

Service Fabric Stateful Actors offer a great programming model to efficiently act as a Device Shadow that models the telemetry and command needs of an IoT device, to allow it to work well with the Backend System as well as other parts of an IoT solution.   As such, SF Actors speed up development time, plus reduce the level of skill required to effectively program and debug potentially complex logic associated with commanding and telemetry.

Keep in mind, with many cloud solutions there is usually no guarantee that difficult problems will not arise when scaling out to 1) service tens of thousands or even millions of IoT devices, or to 2) service high data rates moving to and from the devices.  Such problems often involve throughput and contention issues in accessing storage, the need to use multi-threaded programming techniques, excessive latency, and the need to orchestrate the timing of several different collaborating components in a cloud environment which is eventually consistent by its nature.  Any of these issues by themselves is a challenge to a seasoned developer, and taken together they will likely take a substantial amount of time to get right.  My POC showed me that Service Fabric Stateful Actors can relieve a substantial amount of this burden in the realm of Device Shadows.

In what follows I list what I liked about developing my POC with SF Actors, followed by a list of links that facilitate you learning more about Actors and Service Fabric, rather than explaining them in this blog.

Why I Like Service Fabric Actors as IoT Device Shadows

• Most of the behavior required for Device Shadowing is located close together: It is in the Actor microservice itself or in the resource accessor used to provide system wide access to an Actor. Not much of this behavior is spread widely across the entire system.  This reduces development and maintenance time.
• There is no need to deal with complex multi-threaded code. Actors are single threaded with “turn based concurrency”.  In other words, all the code in one of an Actor’s methods will be completely executed before any of the other methods can begin execution.  This makes development and debugging much, much easier and faster than when dealing with multi-threading.
• One does not have to worry about data persistence concurrency issues. All of the state of an Actor (i.e. the telemetry and command state in a Device Shadow) is persisted in an Actor’s own private state store.  And, that state can only be accessed via an Actor method or property which is guaranteed to use “turn based concurrency”.  So, there is no worry about data access exceptions due to “record locking”, which can happen with a busy traditional database.  And there is no need to use transactions since they are “built in” to Actor state access.
• One does not have to worry about slow or intermittent data access to an Actor’s private state. Service Fabric Stateful Actors are built on top of Service Fabric Reliable Services.  Behind the scenes, Stateful Reliable Services save their state on the hard disk of the virtual machine in the SF cluster that is running the Actor instance.  Thus, there is no network access involved in state access by an Actor.  This makes data access much faster than over a network, and it eliminates the ever present network transient faults of cloud computing than serve to complicate data access.
• There is no need to write code to deal with special considerations to gain massive scalability. By the inherent nature of Service Fabric, its clusters, and Actors (each instance is running as a separate microservice) there is built-in scalability of vast proportions!  The focus shifts from providing scalability in code, to configuring the Service Fabric cluster to provide the required scale.  And configuration takes a whole lot less time and effort.
• The learning curve is quite reasonable. The documentation is good.  And learning to use Actors in the role of Device Shadows is just not that hard!  However there are some advanced scenarios involving complex parallel computations with Actors that are not for the rank beginner.
• The development environment is good. A “development cluster” can be set up on your development system, and it runs exactly the same binaries that a production Service Fabric cluster does.  This is not emulation!  Working with the development cluster through Visual Studio is a very time efficient way to develop and debug code before running it on a non-development cluster on Azure or in your own data center.
• SF provides amazing time saving upgrade capabilities when Actors must have code changes. Upgrades can happen without taking the system down or out of service.  And if an upgrade has problems, the code can be automatically rolled back.  Again, without taking the system out of service.  In general, Service Fabric adds great value in the area of operations, in this and many other ways.

Links Concerning Service Fabric, Actors, and Code Samples Showing Their Use in IoT Solutions

“Microsoft Azure – Azure Service Fabric and the Microservices Architecture”, MSDN Magazine, December 2015.  This is an excellent overview of Service Fabric, plus has a good section on Actors as well.

Overview of Service Fabric.  This Microsoft article provides a broad view of Service Fabric development and operational features, plus contains a few good videos for more in depth knowledge.

Introduction to Service Fabric Reliable Actors.  This Microsoft document is a good place to start learning about Actors.  It also includes links to other detailed documentation for Actors, in the panel on the left.

Getting to Know Actors in Service Fabric. This is a really good in-depth blog on the details of Service Fabric Actors, plus graphically showing how they fit in with other microservices running under Service Fabric.  This is a must read to get up to speed on Actors quickly, IMO.

IoT Actor Code Example:  Service Fabric IoT Sample, from Microsoft by Vaclav Turecek (Sr. Program Manager on the Service Fabric team).

IoT Actor Code Example:  Paolo Salvatori (Microsoft, Italy) provides IoT code examples using Actors, plus several other Service Fabric examples as well.

Azure Code Samples for Service Fabric provides some IoT related Actor samples, plus others as well.

I hope this introduction to Service Fabric Stateful Actors used as Device Shadows spurs you to further investigate their capabilities and how they can be useful to you.

George Stevens

dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at dotnetsilverlightprism.wordpress.com.